I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

What's changed and what's your intention?

This PR wires terminal record-batch metrics through the Flight/client/Flow consumer path.

It builds on #8015, which introduced RecordBatchMetrics.region_watermarks and query-side terminal metric collection.

Changes

• Adds Flight transport support for optional trailing terminal Metrics messages.
• Adds client-side OutputWithMetrics / OutputMetrics helpers so callers can consume terminal metrics without breaking existing Output APIs.
• Adds Flow frontend-client support for requesting and reading terminal region watermarks in both standalone and distributed modes.
• Validates Flow query extensions at the Flight boundary before dispatch.
• Keeps normal query/affected-row behavior backward-compatible when terminal metrics are absent.

Scope

This PR is limited to terminal metrics transport and consumption:

• src/servers/src/grpc/flight.rs
• src/client/src/database.rs
• src/flow/src/batching_mode/frontend_client.rs
• related error/test updates

It intentionally does not include later stale-cursor, incremental-after-seq, benchmark.

Compatibility

Existing client APIs (sql, query, create, alter, etc.) continue to return plain Output.
Terminal metrics are opt-in through the new metrics-aware helper path.

Malformed terminal metrics are rejected as transport/parsing errors instead of being silently ignored.

Tests

• cargo test -p client terminal_metrics --lib
• cargo test -p flow query_with_terminal_metrics --lib

Coverage includes:

• stream terminal metrics roundtrip
• affected-rows terminal metrics roundtrip
• invalid terminal metrics rejection
• invalid Flow extension rejection
• standalone and distributed Flow consumer paths

PR Checklist

Please convert it to a draft if some of the following conditions are not met.

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR requires documentation updates.
• API changes are backward compatible.
• Schema or data changes are backward compatible.